1. The Field of the Invention
The present invention relates to methods for managing connection-oriented hardware media in an I/O subsystem of a computer operating system. More particularly, the present invention relates to a proxy client of an integrating component that provides a generalized interface for connection management so that characteristics of the underlying connection-oriented devices may be represented by the proxy client to applications in a format known by the application program, such as Telephony Application Programming Interface (TAPI) line devices.
2. Present State of the Art
The effectiveness of general purpose stand alone computers, such as the personal computer found in most office environments and laptop computers increasingly used by professionals requiring portability, has been substantially improved by allowing communications between machines over a communications network. Such networking of computers allows the sharing of resources found on one computer with other computers in the network. For example, storage areas having files, printers, modems, and other resources may all be advantageously shared.
Data that is shared between computers can be sent in packets across a physical network connection and read by destination computers. Such packetized network data may be requests for shared resources, data, such as a file, or other information that must be communicated from one computer to the other. As used herein, the term “network data” refers to data or information that is actually transmitted over the communications network between different computers.
The physical network between the different computers can be categorized into two general types. The first type of network makes use of a “connectionless” media wherein the packetized network data contains destination information, such as a network address, and is simply placed on the network by the hardware media (hereinafter referred to simply as “media”) and routed to the destination. A common network interface card that provides access to an Ethernet would be an example of a connectionless media. The destination will recognize the address in the packet and process it accordingly while other destination nodes will simply ignore the packet since it lacks the correct address information.
Another type of physical network utilizes a connection-oriented hardware media, such as telephone modem, cable modem, or ISDN connector. With connection-oriented media, a connection must be made and maintained in addition to sending and receiving packets of information. The connection-oriented media will send and receive data packets directly with the destination node that has matching hardware and with which a connection has been made. Once data is received, it is treated in the same manner by the I/O subsystem. Connection-oriented media are commonly found for Wide Area Network (WAN) implementations.
On a particular computer or node of the network, a network interface card (NIC) or network card monitors the physical communications channel for packets destined for that computer as well as transmits packets of network data destined for other computers. A connection-oriented NIC will first have to make the connection before packets may be sent and received. Once the connection is made, the connection-oriented NIC may receive and send packets as described above depending on the nature of the connection-oriented media. Software components run on the node computer under direction or control of the operating system or architecture for managing and controlling the network card operations. Furthermore, other software components exist to further abstract the network communications channel and provide more and more general networking interfaces for higher layers using their services. The layered approach allows compartmentalization and easier development of network applications.
One model used to provide a structure for layered software component development is the seven-layer ISO model that is well known in the art. While actual implementations of the ISO model do not necessarily rigidly isolate each particular layer as a separate component exposing its own interface to layers above and below, the concepts of the model are generally applicable. For purposes of this disclosure, the lower layers of the ISO model are most at issue, namely, the data link layer implemented by a network card device driver, and the transport and network layers implemented as a transport protocol driver.
Lower level networking functions, such as are discussed throughout this application with respect to controlling a network card and initial processing of packetized network data, are handled by special system software components called drivers that integrate with a host operating system according to a specific architecture and have special privileges for accessing system resources. Throughout this application, reference will be made to the Windows NT® operating system available from Microsoft Corporation and to its specific architecture wherein lies one embodiment of the present invention. Such drivers run in “kernel mode,” meaning they have higher privileges and access to system resources than do “user mode” application process threads. While specific reference is made to Windows NT concepts and terminology, those skilled in the art will recognize that many, if not most, operating systems share similarities relevant to the environment of the present invention.
Because there are different types of transport protocols developed over time by different entities for different reasons, there may be different types of transport protocol drivers acting as software components running on a single host computer system in order to provide the necessary networking capabilities for a given installation. Some common transport protocols include TCP/IP, IPX, AppleTalk®, and others. Each transport protocol driver will communicate with one or more individual network card device drivers in order to send network data over a communications network and receive incoming packets from the communications network.
Furthermore, because there are a multitude of network cards provided by numerous manufacturers, there are a corresponding large number of potential network card device drivers. In order to support full connectivity to the transport protocol drivers, each network card device driver must support the ability to communicate with each different type of transport protocol driver. Because of the complexity of many different variations that could conceivably be connected together due to the layered component approach, building such drivers can be a time intensive process and the nature of the different interfaces each driver must use is illustrated in FIG. 1.
FIG. 1 is a block diagram showing the structure of a plurality of network cards, network card device drivers, and transport protocol drivers that each must interact with system resources and a central database or registry having connectivity information in order to operate properly. Furthermore, each transport protocol driver must support each and every network card device driver for which it may be connected and in like manner each network card device driver must support communicating with each and every transport protocol driver to which it may be connected.
If a new transport protocol driver is introduced, each network card device driver wanting to support the new transport protocol driver may require modification to the source code followed by a re-release and distribution of the executable driver code. Likewise, a new network card device driver may also require a similar re-release. Releasing and distributing software is an expensive process that software companies desire to limit as much as possible.
For example, passing network information arriving on network card 20 controlled by network card device driver 22 to the transport protocol driver 24 requires the transport protocol driver 24 and the network card device driver 22 to be fairly complex in terms of programming effort. This may take significant time for a developer or engineer to create. Note that the network card driver 22 must not only interact with the network interface card 20 but also have an interface 26 to the system resources 28 as well as an interface 30 to the registry 32 containing connectivity information. Through such interfaces and the programming entailed therein, the network card device driver 22 will receive an interrupt that a packet has been received or is available for receipt by having the system execute code in an interrupt handling routine previously registered that makes use of system resources such as RAM for storing the packet.
Furthermore, the network card device driver 22 will use the registry interface 30 to access the registry 32 connectivity information for determining which transport protocol driver(s) will receive the packetized network information. For purposes of this example, the transport driver 24 is the recipient as illustrated by connecting line 34. Note also that the network card device driver 22 must support or be able to communicate with other transport protocol drivers since a variety exist and it is not known at development time which transport protocol driver will be indicated in the control information found in the registry 32 for receiving the network data.
On the other hand, the protocol transport driver 24 must also interface with the system resources 28 and the registry 32 containing connectivity information. Again, in order to support the many available network card device drivers, each transport protocol driver will be a relatively complex software component since the precise network card device driver for interfacing is not known at the time of development.
One advance in the art that has reduced the complexity associated with developing transport protocol drivers and network card device drivers is that of an integrating component that provides an abstracted interface to transport protocol drivers developers and to network card device driver developers. FIG. 2 is a block diagram showing the introduction of an integrating component that reduces the complexity of transport protocol driver development and network card device driver development. In such an environment, an integrating component 36 will have a registry interface 38 for accessing a registry 32 of connectivity information and a system resource interface 40 for accessing system resources 28. Therefore, development of the network card device driver 42 for controlling network card 20 is greatly simplified. The network card device driver 42 must only support an interface 44 to the integrating component 36. In like manner, the transport protocol driver 46 is also further simplified as only an interface 48 to the integrating component 36 may be supported.
The complexity of interfacing directly with the system resources 26 and the registry 32 of connectivity information is now handled by the integrating component 36. Furthermore, the integrating component provides an interface to developers incorporating many services and functionality that will be common to network card drivers and transport protocol drivers allowing the drivers to be developed more efficiently.
Another inherent benefit is that all routing of packets between transport protocol drivers and network card device drivers is managed by the integrating component. A particular transport protocol driver or network card device driver does not need to know the specific interface of the other components processing the same network packet. In other words, any network card device driver written to the integrating component 36 will be able to communicate with any available transport protocol that is also written to the integrating component 36 as determined by the connectivity information contained in the registry 32 and vice versa with respect to transport protocol drivers communicating with network card device drivers.
Besides providing quicker transport network card device driver development, the use of an integrating component 36 also facilitates multi-platform support. The integrating component interface may be supported on many different platforms, effectively encapsulating the details of actual interfacing with a particular operating system and environment. A driver developer generally needs to write the driver only one time and simply recompile the driver on any system that has the integrating component 36 supported thereon.
One technology for integrating network card device drivers to transport protocol drivers is the Network Driver Interface Specification (NDIS) technology implemented on the Windows NT operating system as the NDIS wrapper device driver. The NDIS technology is also supported on other systems, such as the Windows95® operating system, in order to support cross platform support of network card device drivers and transport protocol drivers. The integrating component manages all interaction with system level services and hardware to further reduce development complexity of connected drivers. For example, the NDIS wrapper manages initial interrupt processing, system memory allocations to connected drivers, allocation to other hardware resources, etc. as well as providing packet routing capability between network card device drivers and transport protocol drivers.
Referring now to FIG. 3, a logical diagram showing a number of different parts of software for a connection-oriented hardware media that utilizes an integrating component, such as integrating component 36 explained previously, is presented. FIG. 3 represents one way of handling connection-oriented hardware media that utilizes an integrating component but where the connection-oriented device driver must still provide a connection interface and connection management functionality that must be replicated for each and every connection-oriented device driver. In other words, every connection-oriented hardware manufacturer must develop and provide, as part of the device driver, the connection management ability. Furthermore, in many instances an application must be programmed to a proprietary connection interface which further limits the flexibility having an integrating component.
Connection-oriented hardware adapter 52 provides access to a certain media type and is controlled by the connection-oriented device driver 54 as represented by arrow 56. This control includes all the connection creation in management control as well as the packetized network data control that is not associated with the integrating component 58. The connection-oriented device driver 54 communicates with the integrating component 58 as indicated by arrow 60 in the same manner as explained previously in FIG. 2 to provide a data path and to a connection-oriented data transport 62 (as indicated by arrow 64). Finally, the application 66 communicates with the connection-oriented data transport 62, again, as indicated by arrow 68. Note that the arrows used to indicate communication between the various components may in fact indicate communication through additional components. For example, communication may be through an operating system or there may be additional components. FIG. 3 is simplified in order to focus on the two different channels that an application 66 would use to manage connection-oriented hardware.
Arrow 68 may consist of a path of various components in transporting data to and from the data transport 62 that are unimportant for this discussion. For example, the application may communicate with a WinSock communications component that may communicate with yet other components before data arrives at the data transport. All such components are incorporated as part of arrow 68.
Besides the data channel through the data transport 62 in the integrating component 58, the connection-oriented device driver 54 provides a connection channel to the application 66 by means of a connection interface 72 that allows communication between the application 66 and the connection-oriented device driver 54 as indicated by arrow 74. This connection interface 72 can be either proprietary or standardized but in either case must be provided by the connection-oriented device driver 54.
Furthermore, the actual connection management functionality 76 is also included in the connection-oriented device driver 54 thereby increasing significantly in some instances the amount of development for a connection-oriented device driver 54. The connection management functionality 76 includes media-specific control and protocol information for creating and managing a connection over the media by the connection-oriented hardware adapter 52. For example, for Asynchronous Transfer Mode (ATM) media, a certain set of signaling protocols and control information is used, regardless of the actual hardware created by different manufacturers. In other words, each manufacturer must create the same connection management protocol functionality for an ATM card as every other manufacturer. This represents a redundant development effort, particularly when the connection management functionality constitutes a very large portion of the development of the connection-oriented device driver 54 and such connection management functionality is readily defined by adopted standards.
Referring now to FIG. 4, a logical diagram is shown that illustrates the environment in the Microsoft NT operating system. This diagram is equivalent in its functional nature to that shown in FIG. 3 but introduces concepts specific to the NT environment. Note that this is only one example of components used to make and use a connection in a connection-oriented architecture and others do exist.
The application program 78 will be written to communicate with a Win32 communications applications programming interface (API) 80, such as WinSock, as indicated by arrow 82 in order to send and receive data over a connection-oriented data channel with the appropriate connection-oriented transport as has been explained previously. For creating and maintaining a connection, the application 78 may communicate through a Telephony API 84 or TAPI 84 as indicated by arrow 86, or some other interface. Both the telephony API 84 and the Win32 communications API 80 reside in user mode for the NT operating system. Note that elements of the Win32 communications API 80 may be used for creating a connection.
A demarcation between user mode and kernel mode is indicated by dash line 88. Furthermore, there may be additional kernel mode components and/or user mode components that are used to make the communication channels as shown.
Connection-oriented hardware device driver 90 controls the connection-oriented hardware adapter 92 as indicated by arrow 94. For purposes of the data channel, the connection-oriented device driver 90 will communicate bi-directionally with the integrating component 96 as indicated by arrow 98. The data channel is completed by having the integrating component 96 communicate with the connection-oriented data transport 100 as indicated by arrow 102 and further having the data transport 100 communicate with the Win32 API library 80 as indicated by arrow 104. The data channel aspect is relatively known in the art with respect to connectionless device drivers. Because the integrating component 96 incorporates much common functionality common to all network data communications, connectionless device drivers are written in a much simplified fashion.
Again, the connection channel may require substantial effort on the part of the device driver developer. For example, the connection-oriented device driver 90 must provide a connection interface 106 that will communicate with the telephoning API 84 as indicated by arrow 108. Every connection-oriented device driver developer will need to provide such an interface. Furthermore, the connection management functionality 110 that is specific to a particular media upon which the connection-oriented hardware communicates (e.g., ATM, ISDN, etc.) can amount to a substantial amount of development effort. Again, such development effort is duplicate across many developers that essentially implement the same functionality.
Because of the added driver development effort required in order to provide a connection management interface that is either proprietary or that interfaces with existing application level interfaces (e.g., TAPI), it would be desirable to provide such connection interface in an abstracted form so that the connection-oriented device driver development may be simplified. Furthermore, since applications are generally written to a higher level interface, such as TAPI, rather than to a lower-level I/O subsystem integrating component, such as NDIS, it would be highly beneficial to represent the connection functionality provided by the I/O subsystem in a way that is readily implemented by the higher level components, such as TAPI. This allows the device characteristics to be more immediately available to the applications without having the application be programmed to the driver subsystem interface. This is beneficial in that applications can take advantage of the extended connection capabilities with little or no modification.